home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload Trio 2
/
Shareware Overload Trio Volume 2 (Chestnut CD-ROM).ISO
/
dir42
/
dbind2.zip
/
DBINDENT.DOC
< prev
next >
Wrap
Text File
|
1993-10-16
|
5KB
|
94 lines
Looking for a way to make your program listings easier to read? Ever think
you'd go crazy trying to find mismatched IF...ENDIFs or figuring which ENDDO
goes with which DO WHILE? DBINDENT.PRG is a dBaseIII+ program which evolved
over a period of time to make such tasks much easier.
You'll need a .DBF file named DBINDENT consisting of 1 character type field
named ENT. My DBINDENT.DBF has a field width of 120 so the ends of deeply
indented lines won't get lost; you can make it any size you like up to 254.
Sure, going over 80 makes lines extend past the right edge of the screen on
most monitors when you view the data but I use an editor that lets me get to
that data, too. (Try QEdit v2.15, a shareware package from SemWare available
on CompuServ; for the power it has it's a fantastic buy. I use it in place
of 'real' word processors so much I've forgotten my WordPerfect commands.)
The program is pretty straightforward in the way it's used. I always clear
anything left over in DBINDENT.DBF and set it up as follows:
USE DBINDENT
ZAP
CLEAR ALL
APPEND FROM <file spec> SDF
Unless the file being appended is in your dBase default directory, a path must
be included as part of <file spec>. If the file name extension for the file
being 'absorbed' is anything except .DBF, include it in <file spec>, too. And
unless the file is a true dBase (or compatible xBase) file, be sure to include
the SDF file type indicator at the end of the APPEND FROM command.
At this point you simply enter the command DO DBINDENT at the dBase prompt.
DBINDENT.PRG first trims empty space from the left end of each line, then
looks for the following commands to indent or de-indent as appropriate:
(DBINDENT looks for these commands in both their long or short forms.)
DO WHILE ENDDO
IF ENDIF ELSE
DO CASE ENDCASE OTHERWISE
PROCEDURE RETURN PARAMETERS
It 'temporarily de-indents' ELSE, OTHERWISE and PARAMETERS statements so
they're even with IF, DO CASE AND PRODCURE lines for easier reading and all
are capitalized unless a TEXT command is found; TEXT...ENDTEXT lines are not
affected at all. And in the case of @ SAY...GET lines, upper/lower case is
not affected plus you have the option of setting the line even with the left
margin. Comment lines can be indented, left flush at the left end of the line
or deleted according to your preference with minor changes. It's also easy
to disable the capitalizing of lines other than @ SAY...GETs and TEXT.
When you're all done, the command
COPY TO <file spec> DELI WITH BLANKS
will give you an ASCII type listing. It's not
necessary for the <file spec> in the COPY TO command be the same as in the
APPEND FROM command. As a matter of fact, it might be wise to use a similar
but different name until you test the indented program.
I use DBINDENT quite often with good results and, while it takes a little time
to process listing with a large number of lines, it been worth the time as a
debugging tool. Besides, it leaves you with a listing you're not ashamed to
show to your boss without spending hours indenting with an editor, too. Let
him (or her as the case may be) think you spent all night slaving in front of
your monitor instead of lounging in front of the TV anyway; maybe you'll get
that raise you deserve.
(Another hint: If you use && to add comments to the ends of command lines and
tried to remove them you've probably found that && in a command, even if you
enclose it in quotes, truncates everything to the right in the command itself
so it doesn't work. You can remove these comments and leave the rest of the
line intact with the following command while using DBINDENT:
REPLACE LINE WITH LEFT(LINE, AT(("&"+"&"), ENT) -1) FOR ("&"+"&") $ LINE
A companion program with also uses DBINDENT.DBF is CHKLOOPS.PRG. This program
deletes everything in the file, then recalls selected commands, (IF, ENDIF, DO
WHILE, ENDDO, etc) and provides a count for each. If the counts don't match,
you can copy the results to a separate file so search out the mismatched
command. (I'm forever ending DO WHILEs with ENDIFs.) There are two reasons
CHKLOOPS should be used AFTER running DBINDENT. First, running DBINDENT
before CHKLOOPS makes it easier to find errors and secondly, CHKLOOPS does NOT
recall all the original statements when it's done running.
So there you are. Good luck and good hunting. I hope you find that DBINDENT
and/or CHKLOOPS are as useful to you as they have been for me.
=============================================================================
My apologies to any of you who may have downloaded the 10Oct93 version of this
file - I guess I let myself get too anxious about finally having something
worth contributing and didn't bother to test some last minute changes I'd made
in my attempt to clarify the program's internal documentation. If you had
trouble with DO CASE and/or DO WHILE indentations, they are taken care of in
this revised version. And, as before, comments are invited.
Thank you for your patience and thank you for giving me another chance.
Bob V, CompuServ 73230,2136